其实在前边的AUTOSAR 的基本概念一文中已经提过BSW基础软件层的概念了,接下来我们重新梳理下BSW相关内容。
BSW 指的是基础软件层(Basic Software)。从本质上来说,它的作用是对整个电子控制单元(ECU)进行分层封装,一直封装到操作系统(OS)这一层。
打个比方,大家都熟悉 Windows 操作系统,它具备很强的兼容性,能够在配置各不相同的设备上运行,像不同的 CPU、GPU 以及主板等硬件环境下都可以正常使用。同样的道理,我们可以把 ECU 类比成电脑硬件,而 ECU 上的主芯片就相当于电脑中的 CPU,AutoSAR OS 在这个情境中则可以看作是 Windows。通过这样的比喻,想必大家能更容易理解 BSW 的概念了。
不过,在 BSW 当中,我们并不是特别关注其中的操作系统部分,因为它可以通过软件直接生成。我们重点关注的是,怎样为我们的操作系统提供必要的硬件和软件支持。毕竟,现实中存在着各种各样、千奇百怪的 ECU 产品,为了满足不同 ECU 产品中操作系统以及上层应用的需求,就需要进行不同的配置设置,而这恰恰就是 BSW 的职责所在。
为了更好地将硬件逐步剥离开来,BSW 精心设置了三层软件层。有意思的是,这三层软件层呈现出越往上与硬件关系越小的特点,这样的分层结构有助于更清晰、高效地实现其功能。
接触过 Arm 的人对“库”这一概念并不陌生。简单来说,“库”是将芯片里寄存器的相关操作全部封装成 API 函数,方便用户调用。微控制器硬件抽象层的原理与“库”相似,它负责把芯片具备的各项功能逐一封装成一个个 API 函数,这些 API 函数由 AutoSAR 统一规定。
针对不同的芯片,微控制器硬件抽象层能使提供给上层的接口保持完全一致。完成相应配置后,同一操作可在不同芯片上顺利执行,实现兼容性,方便开发及后续使用。
微控制器硬件抽象层聚焦于对 ECU(电子控制单元)上主芯片进行抽象与封装,而 ECU 抽象层的范畴更广,它针对的是整个 ECU 进行封装操作。
具体而言,在 ECU 当中,除了主芯片之外,还配备有其他诸多设备,像外置存储、外置看门狗等等。ECU 抽象层所做的工作,就是把 ECU 上涵盖主芯片以及这些附属设备在内的全部硬件进行统一的封装处理。
不过需要注意的是,尽管 ECU 上存在各种各样的设备,但这些设备在实际运行中大多需要依靠主芯片来进行控制。例如外置看门狗,它必须要和主芯片建立连接,然后借助主芯片提供的接口来完成相应配置工作。所以,从底层的实现角度来看,ECU 抽象层依然离不开微控制器硬件抽象层(MCAL)的支持,MCAL 为其提供了必要的底层支撑,以此保障整个 ECU 抽象层功能的有效实现。
服务层涵盖了操作系统(OS),它发挥着重要的整合作用,会把下层各个部分所具备的功能统一汇聚于此。在这个过程中,服务层会针对所有与硬件相关的功能进行抽象处理,使其转化为一个个具体的应用服务。
例如在通信方面,它会把 CAN(控制器局域网络)、I2C(集成电路总线)以及串口等多种不同类型的通信方式统一抽象成 COM 通信。如此一来,处于上层的应用层在使用通信功能时,无需去深入了解具体是通过哪种通信方式来实现的,大大降低了应用层与硬件之间的耦合度,方便了应用层的开发与使用。
可能大家对于这里所提到的“服务”概念理解起来会有一定难度,其实大家可以将其类比为一种 API(应用程序编程接口),只不过它相较于普通的 API,具备更高层级的封装特性,和应用层之间有着更为紧密的关联,能够更好地服务于应用层的各种功能实现需求。
具体功能:(这里的具体流程将在后续详细讲解)
诊断(Diagnostics)
存储管理(NVRAM Management)
看门狗管理(Watchdog Manager)
通信(Communication)
操作系统(OS)
调度管理(Schedule Manager)
ECU状态管理(ECU state management)
通信通道管理(Com Channel Management)
AUTOSAR复杂驱动可以说是一个颇为独特的存在。之所以说它独特,是因为它并不隶属于AUTOSAR基础软件(BSW)的三层结构范畴之内,就仿佛是“不在五行中,跳出三界外”一般。
BSW的三层结构有着明确的功能划分与定义,然而在实际的应用场景中,总会存在一些功能是这三层结构未曾涵盖,但又确实会被用到的情况。而AUTOSAR复杂驱动所扮演的角色恰恰就是补充,那些在BSW三层结构里没有被定义的功能,都可以在复杂驱动中进行相应的编写与实现,以此来满足实际项目中多样化的功能需求。
下面我们通过一张图来进行说明,在这张图中,主要涵盖了几大功能板块,分别是存储功能、通信功能、I/O功能以及板载功能(这里的板载指的是电子控制单元,即 ECU 上的其他设备)。
为了让大家更清晰地分辨不同层级,我采用了颜色对各个层级进行了区分,像 AUTOSAR 基础软件(BSW)的服务层、ECU 抽象层等各层都能一目了然。
仔细观察这张图可以发现,除了 I/O 功能外,基本上每一种功能都是由竖向的三层结构所组成的。而从横向角度来看,展示的则是每层所包含的具体功能。
接下来,我会针对图中的部分功能展开详细的讲解。当下大家先对这张图有一个大致的了解即可,不过需要强调的是,这张图是比较重要的,它就如同一个目录一样,后续要学习的内容基本上都是围绕着对这张图里所有模块的阐释展开的。相信等大家继续深入学习之后,再回过头来看这张图时,应该就能自行将它画出来了。
系统服务是一组模块和功能,可被所有层的模块使用。例如实时操作系统(包括定时器服务)和错误管理器等。为应用和基础软件模块提供基本服务,确保整个系统的稳定运行和各模块之间的协调工作。
错误管理器(Error Manager):用于处理系统中的错误事件。
ECU 状态管理器(ECU State Manager):部分依赖于 ECU 硬件和应用,用于管理 ECU 的状态。
看门狗管理器(Watchdog Manager):确保系统的正常运行,防止系统死机等情况。
时间服务(Time Service):提供时间相关的功能,可能与 μC 的能力相关。
同步时间(Synchronized Time):用于实现系统内时间的同步。
基本软件模式(Basic Software Mode):可能涉及到基本软件的运行模式设置等。
AUTOSAR OS:遵循 AUTOSAR 标准的操作系统,为系统提供基础的操作系统功能。
例如,在汽车电子系统中,实时操作系统可以确保各个任务按照预定的时间和优先级执行,定时器服务可用于周期性的操作,如传感器数据的定时采集等;错误管理器能够及时发现并处理系统中错误,如通信错误、硬件故障等,保障系统的可靠性;ECU状态管理器根据车辆的不同状态(如启动、运行、休眠等)来管理 ECU 的工作模式和资源分配;看门狗管理器则通过定时喂狗机制防止系统出现死锁等异常情况,保证系统的稳定性。这些系统服务相互协作,共同为汽车电子系统的高效运行提供支持。
众所周知,目前用户常用的 ROM 存储方式主要有两种,即 EEPROM 和 FLASH 仿 EEPROM。而从存储位置来看,又可分为片内存储与片外存储这两种情况。
基于此,通常就会产生 4 种 ROM 存储方式,具体如下:
主芯片片内 FLASH 仿 EEPROM:存储在主芯片内部,采用 FLASH 仿 EEPROM 方式进行存储。
主芯片片内 EEPROM:前提是芯片内部具备 EEPROM 才行,不过许多相对低端的芯片是不带有片内 EEPROM 的。
板载片外 FLASH 仿 EEPROM:存储位置在板载的片外区域,运用 FLASH 仿 EEPROM 的存储模式。
板载片外 EEPROM:同样是位于板载的片外位置,采用 EEPROM 进行存储。
需要注意的是,EEPROM 和 FLASH 都属于 ROM 的范畴,在相同容量大小的情况下,Flash 的成本相对更低一些,但其擦写方式存在特点,只能按块擦写,无法按位擦写。若要让 Flash 实现按位擦写,就需要先将 Flash 中原有的数据备份一份,接着修改期望改动的位,然后按块擦除,最后把改写好的数据重新烧录回原块中。由于这一过程需要软件介入处理,所以被称作 FLASH 仿 EEPROM。
特别提醒大家,对于图中的各个模块,一定要对照下方的解释认真理解,搞清楚其具体原理和运作方式,切不可走马观花或者敷衍了事。即便当下不太能看懂,也要坚持看完,随着后续学习的深入,慢慢就能理解了。我们暂时并不需要真正去钻研其代码是如何实现的,所以针对这些模块,我们着重介绍其功能与工作流程就行,关于更详细的实践内容会在后续的实践篇中讲解。
就片内存储而言,其原理相对简单,图中两种颜色的箭头分别代表了从 EEP 和 FLASH 存储数据的流向,这些数据最终会抵达主芯片上的 EEPROM 和 FLASH,并且整个过程不经过片外驱动、SPI 以及片外设备。
对于使用过片外存储的同学来说,可能会相对熟悉一些情况,通常大部分片外存储都是采用 SPI 通信,并结合一些其他控制命令来实现的。要是我们手动去操作的话,就需要查阅对应存储芯片的手册,然后进行 SPI 配置,再把定义好的命令通过 SPI 发送出去。而 AutoSAR 在这方面其实也是类似的原理,只不过它把这些流程都封装成了模块,使得整个流程看上去更加清晰明了。
在汽车领域中,通常情况下都会采用 CAN 总线来进行通信,我们这里以CAN总线为例介绍通信服务,其他总线也是一样的。后续在实践篇里,会专门设置一节内容用于开展有关通信(communication)方面的实验。
BSW 中的这些章节内容往往比较晦涩难懂,理解起来会有一定的难度,但还是希望大家能够耐着性子先把它们浏览一遍,在脑海里留下一个大致的印象就行。等之后看实践篇的时候,再回过头来看这些内容,理解起来就会轻松许多。如图所示,CAN 通信栈主要由多个层次和模块组成,从下至上依次为:
I/O Drivers(输入 / 输出驱动):包含了如 DIO Driver(数字输入输出驱动)等,负责处理与外部硬件的基本输入输出操作,是整个通信栈与物理世界交互的基础。
Communication Drivers(通信驱动):其中有 SPIHandler Driver(串行外设接口处理驱动)和CAN Driver(CAN 驱动)等。CAN Driver 直接与 CAN 总线进行交互,实现数据的收发等底层操作;SPIHandler Driver 则用于处理与 SPI 相关的通信任务,SPI(Serial Peripheral Interface,串行外设接口)常用于微控制器与其他外设芯片之间的通信。
Communication Hardware Abstraction(通信硬件抽象):这一层提供了对底层硬件的抽象接口,使得上层软件模块能够以一种统一的方式与硬件进行交互,而无需关心具体的硬件细节。
CAN Interface(CAN 接口):作为通信硬件抽象层的一部分,它进一步封装了与 CAN 总线相关的硬件操作,为上层的 CAN 通信服务提供了一个更简洁、统一的接口。
CAN Transceiver Driver(CAN 收发器驱动):负责驱动 CAN 收发器芯片,实现 CAN 信号的电平转换等功能,确保微控制器能够与 CAN 总线进行物理连接和通信。
Driver for ext. CAN ASIC(外部 CAN 专用集成电路驱动):如果系统中使用了外部的 CAN 专用集成电路(Application-Specific Integrated Circuit),则该驱动用于与之交互,实现特定的 CAN 功能或扩展 CAN 通信能力。
Communication Services(通信服务)是 CAN 通信栈的核心部分,包含了多个重要的模块,如:
Large COM(大型通信模块):可能用于处理较大规模的数据通信任务,提供更强大的通信功能和管理能力。
AUTOSAR COM(AUTOSAR 通信模块):遵循 AUTOSAR(Automotive Open System Architecture,汽车开放系统架构)标准,实现了标准化的通信接口和服务,便于不同厂商的软件组件之间进行互操作和集成。
Com Manager(通信管理器):负责管理整个通信栈的通信流程和资源,协调各个模块之间的工作,确保通信的顺利进行。
Diagnostic and Trace Log(诊断和跟踪日志):用于记录通信过程中的诊断信息和事件跟踪日志,方便故障排查和系统调试。
PDU Router(协议数据单元路由器):根据预先设定的路由规则,将不同来源和目的的协议数据单元(Protocol Data Unit)进行路由和转发,实现数据在不同模块或网络之间的传输。
CAN Transport Protocol(CAN 传输协议):定义了在 CAN 总线上传输数据的协议和规则,确保数据的可靠传输和正确解析。
CAN State Manager(CAN 状态管理器):负责管理 CAN 总线的状态,如总线的初始化、唤醒、睡眠等状态转换,以及对总线错误的检测和处理。
Generic NM Interface(通用网络管理接口):提供了一个通用的网络管理接口,用于实现网络管理功能,如网络唤醒、睡眠等操作,确保整个网络的节能和高效运行。
CAN NM(CAN 网络管理):专门针对 CAN 网络的网络管理模块,实现了 CAN 网络的节点管理、网络状态监控等功能,保证 CAN 网络的稳定性和可靠性。
在 AUTOSAR 架构中,基础软件层的 Diagnostics 功能分布在多个模块中,这些模块协同工作,共同实现全面的诊断功能。
Watchdog Manager(看门狗管理器):用于监控系统的运行状态,防止系统出现死机等异常情况。如果系统在规定时间内没有 “喂狗”,看门狗管理器会触发相应的错误处理机制。
Function Inhibition Manager(功能抑制管理器):当检测到某些错误或异常情况时,该管理器可以抑制相关功能的运行,以避免错误进一步扩大或影响其他系统功能。
Default Error Tracer(默认错误追踪器):所有在基础软件中检测到的开发错误都会被报告给默认错误追踪器,它负责记录和追踪这些错误信息,为开发人员提供调试和问题排查的依据。
Diagnostic Event Manager(诊断事件管理器):负责处理和存储诊断事件(即错误)以及相关的 FreezeFrame 数据。FreezeFrame 数据是指在错误发生时系统的关键状态信息,如传感器数值、控制变量等,这些数据对于准确诊断问题根源非常重要。
Diagnostic Communication Manager(诊断通信管理器):提供了一个通用的 API(应用程序编程接口)用于诊断服务。它使得不同的软件组件能够通过统一的接口进行诊断通信,方便了诊断功能的集成和使用。
Diagnostic Log and Trace(诊断日志和追踪):支持应用程序的日志记录和追踪功能。它收集用户定义的日志消息,并将其转换为标准化格式,便于后续的分析和处理。这些日志和追踪信息可以帮助开发人员和维护人员了解系统的运行情况,及时发现潜在的问题。
在汽车电子系统中,ECU 故障处理是保障车辆正常运行的关键环节。当故障发生时,NVRAM Manager 及其底层模块会迅速将故障内容精准记录于 EEP 或 Flash 中,确保信息的持久存储。而维修时,由于无法直接读取存储内容,CAN 通信便发挥重要作用,借助 DCM 等 communication 模块,将故障信息高效传输至维修师傅的诊断设备,为维修提供有力支持。同时,故障发生瞬间,系统会即刻启动应急处理功能,或限制功能,或启用备用,如同汽车的 “安全卫士”,在故障面前筑起一道防线,既方便维修又保障行车安全,让汽车电子系统在面对突发状况时也能有条不紊地运行。
基础软件层的I/O功能涵盖多个方面,且涉及诸多相关模块,在介绍I/O功能时,会用到一些关键模块,相关模块都进行了高亮显示,并将其放大展示于右边图中呈现子模块(这些子模块是BSW中最小的功能单位,例如ADC子模块)。需要明确的是,此处的I/O并非等同于常见的GPIO,它实际包含了DIO(数字输入输出,与单片机上的GPIO类似)、ADC(模数转换)以及PWM(脉冲宽度调制)。